Add freestanding RTTI::to, RTTI::is, RTTI::isAny #4696
Conversation
& tests for them
vlstill
added
the
core
|
I would merge this into |
I can rename the header. To me it is quite tightly bound Also is not just casts but traits too (and concepts in future). I don't have a better name right now thought, naming is hard :-(. |
|
I think the name of the header is fine. There might be some other utils in the future (e.g. some kind of reflection or typeid name or whatever). |
| /// A trait that check T is custom-RTTI-enabled. Works just like standard property type traits. | ||
| /// One would normally use the _v variant. | ||
| template <typename T> | ||
| struct has_rtti : std::is_base_of<RTTI::Base, T> {}; |
There was a problem hiding this comment.
There are two pieces of RTTI in general:
- One needs to be derived from
RTTI:Base(plus all its bases must be derived fromRTTI::Base) - One has appropriate methods implementation (e.g. via
DECLARE_TYPEINFO-kind macro)
I think it's ok to check just for the base class here – TypeInfo will check for the whole set of constraints anyway should the RTTI methods are invoked.
There was a problem hiding this comment.
Yes, I'd say being derived from RTTI::Base without the proper macros is definitely a bug, so firing a static_assert instead of the proper SFINAE-enabling failure in that case seems fine to me.
| */ | ||
|
|
||
| /// @file | ||
| /// @brief Utilities that help with use of custom-RTTI-enabled classes. |
There was a problem hiding this comment.
Maybe worth mentioning in docs/C++.md?
Names like |
Yes, that's common problem is that |
I agree these kinds of headers can accumulate a lot of unrelated stuff. But we can always split it if there is more. I presume some patterns would start to emerge. Currently there are two kinds of stuff in the header, traits and cast functions and the second depends on the first, so naming it more concretely is tricky. |
This PR adds
rtti_utils.h(split so that it can be included only when needed, ideally just to .cpp files). It contains type traits which help with use of RTTI and, more imporantly it adds three freestanding function-like objects (using similar principle as the C++20 ranges):The names should make it quite clear what these are... they are freestanding wrappers over
->toand->is.nullptris passed into them, they just return nullptr/false.isAny<Ts...>is variadic and accepts any (non-zero) number of type arguments and checks if the passed object is instance of at least one of them.This makes some uses of the RTTI simpler, especially in cases where:
[](const IR::Node *t) { return t->is<IR::Declaration>(); }in standard algorithms;foo->template is<IR::Constant>()which is quite ugly in my opinion.